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The  aim  of  this  performance  evaluation  is  taofold:  (1)  to  devise  bench¬ 
marking  strategies  for  and  apply  benchmarking  methodologies  to  the  measurement 
of  a  prototyped  database  system  in  multiple  backend  configurations,  and  (S)  to 
verify  the  performance  claims  as  projected  or  predicted  by  the  designer  and 
implementor  of  the  multi-backend  dat^ase  system  knoivn  as  MBD6. 

Despite  the  limitation  of  the  backend  hardware,  the  benchmarking  experi¬ 
ments  have  proceeded  well,  producing  startling  results  and  good  insights.  G|/ 
collecting  macroscopic  data  such  as  the  response  time  of  the  request,  the 
external  |  performance  measurements  of  MBD6  have  been  conducted.  ool  lecting 
microscopic  data  such  as  the  time  entering  and  leaving  a  system  process,  the 
internal  performance  measurements  of  1036  have  been  carried  out.  Methodolo¬ 
gies  for  constructinj  test  databases,  directories,  and  requests  have  been  dev¬ 
ised  and  utilized.  The  performance  evaluation  studies  verify  that  (a)  when 
the  database  remains  the  same  the  response  time  of  a  request  can  be  reduced  to 
nearly  half,  if  the  number  of  beckends  and  their  disks  is  doubled;  (b)  when 
the  response  set  of  a  request  doubles,  the  response  time  of  the  query  remains 
nearly  constant,  if  the  number  of  backends  snd  their  disks  is  doubled.  ■  These 
were  the  performance  claims  of  k036  as  predicted  by  its  designer  and  implemen- 


1.  INTRODUCnCN 


The  multi-beckend  databese  system  (|i/ED6)  is  a  database  system  designed 
specifically  for  capacity  groivth  and  performance  enhancement.  consists 
of  two  or  more  minicomputers  and  their  dedicated  disk  systems.  One  of  the 
minicomputers  serves  as  a  control  ler  to  broadcast  the  requests  to  and  receive 
the  results  from  the  other  mini  computers,  which  are  configured  in  a  parallel 
manner  and  are  termed  as  backends.  All  the  backend  minicomputers  are  identi¬ 
cal,  and  run  identical  software.  The  database  is  evenly  distributed  across  the 
disk  drives  of  each  backend  by  way  of  a  cluster-based  data  placement  algorithm 
unknown  to  the  user.  User  access  to  the  kBD6  is  accomplished  either  via  a 
host  computer,  which  in  turn  communicates  with  the  IlfiDG  controller,  or  with 
the  controller  directly.  Communication  between  the  controller  and  back¬ 
ends  is  accomplished  using  a  broadcast  bus.  An  overview  of  the  system  archi¬ 
tecture  is  given  in  Figure  1. 

There  are  two  basic  performance  claims  of  the  multi-backend  database  sys¬ 
tem,  which  have  been  projected  in  the  original  design  goals  [^iaSla, 
HsiaSlb] .  The  first  claim  states  that  if  the  database  size  remains  constant, 
then  the  response  time  of  requests  processed  by  the  system  is  inversely  pro¬ 
portional  to  the  multiplicity  of  backends.  This  claim  implies  that  by  increas¬ 
ing  the  number  of  backends  in  the  system  and  by  replicating  the  system 
software  on  the  new  beckends,  kfiDS  can  achieve  a  reciprocal  decrease  in  the 
response  time  for  the  same  requests.  The  second  claim  states  that  the 
response  time  of  requests  is  invariant  when  the  response  set  and  the  multipli¬ 
city  of  backends  increases  in  the  same  proportion.  This  claim  implies  that 
when  the  database  size  grows,  the  response  set  for  the  same  requests  wi  1 1 
grow.  E|y  increasing  the  number  of  backends  scoordingly,  kED6  can  nbintain  a 
constant  response  time. 

In  this  psper  we  provide  a  preliminary  evaluation  of  the  validity  of  the 
II/ED6  performance  claims.  The  mein  focus  of  this  paper  is  on  the  external 
performance  measurement  of  KlBOS.  The  external  performance  measurement  evalu¬ 
ates  a  system  by  col lecting  the  response  times  of  requests.  External  perfor¬ 
mance  measurement  is  a  macroscopic  evaluation  of  the  system.  Ingres,  Oracle, 
and  the  Britton-Lee  JEht/BOO,  have  all  been  evaluated  using  external  perfor¬ 
mance  measurement  techniques  [Stra64,  Schi84].  We  also  seek  to  provide  some 
insight  into  the  intemsi  performance  of  ItBDS.  Internal  performance  measure¬ 
ment  provides  a  microscopic  view  of  a  system,  by  ool  lecting  the  times  of  the 


work  diwtrifautod  and  parforaad  bjf  tha  ^yataw  ooaponanta. 

lha  ranaindar  of  thia  papar  ia  organizad  aa  followa.  In  Saction  2  wa 
ppovida  a  briaf  ovarviaw  of  tha  aulti-backand  databaaa  pyataa.  In  Saction  3 
wa  diacuaa  tha  ganaral  taatir^  atratafly  that  waa  uaad  to  avaluata  tha  ay^atam. 
In  Saction  4  wo  axamina  tha  evaluation  raaulta.  Finally,  in  Saction  5  wa  eon- 
cluda  this  paper  and  aummariza  tha  raaulta. 

2.  TtC  ia.TI-eM]e€>  DATABASE  SVSTB4  (kBDQ 

Iba  currant  hardware  configuration  of  MBD6  oonaiata  of  a  VAX-11/780  (>MS 
06)  running  aa  tha  control  lar  and  two  PCP-ll/44a  (RSK-llM  OQ  running  aa  bock- 
anda.  Intarooaputar  oonaunication  ia  aupportad  by  three  porallai  ooaaunication 
linka  (pQL-llBa),  which  is  a  tima-di visioned  wultiplaxad  bus.  lha  iaplaaianta 
tion  efforts  are  documented  in  [Karr82,  Ha62,  BoynSSa,  DamuBi] .  MDS  is  a 
wasaaga  oriented  ayatam  (see  [BqyneSb]).  In  a  massage-oriented  Q^tam,  each 
process  corresponds  to  one  ayatam  function,  these  processes,  then,  oonawnicata 
among  thamaelvea  fay  passing  meaoagaa.  User  requests  are  passed  between 
processes  as  messages,  the  maaaaga  paths  between  processes  are  fixed  for  the 
system,  the  kBOS  processes  are  created  at  the  start-up  time  and  exist 
throughout  the  entire  running  time  of  the  ayatam. 

In  the  rest  of  this  section  wa  begin  by  discussing  the  data  model  of 
liGD6,  the  attribute  based  data  model,  then,  we  present  a  brief  review  of  the 
attribute  baaed  data  languaga  (AEOL)  of  llEDG  by  focusing  on  the  retrieve 
request  only.  Next,  wa  diacuaa  the  directory  structure  used  in  the  ayatam, 
since  it  plays  an  integral  role  in  the  specification  of  the  test  database  (see 
Section  S) .  Lastly,  we  overview  the  execution  of  a  RE1RIBE  request,  to  pro¬ 
vide  a  general  overview  of  the  structure  and  the  operation  of  I6D6. 

2.1.  The  Attribute  Baaed  Osta  Modei 

In  the  attribute  based  data  model,  data  is  modeled  with  the  constructs: 
database,  file,  record,  attribute-value  pair,  directory  keyword,  directory, 
record  body,  keyword  predicate,  artd  query.  Informal  ly,  a  database  oonsists  of 
a  collection  of  files.  Each  fi le  oontains  a  group  of  records  which  are 
characterized  fay  a  unique  set  of  directory  keywords.  A  record  is  oorqxssed  of 
two  ports.  The  first  part  is  a  cot  lection  of  attribute-value  pairs  or  key¬ 
words.  An  attribute- value  pair  is  a  mwibar  of  the  Cartesian  product  of  the 
attribute  name  otkI  the  value  domain  of  tha  attribute.  As  an  example,  <P0PU- 


LATIQN,  2S00Q>  is  an  attributa-valua  pair  having  25000  as  tha  valua  for  tha 
population  attributa.  A  racord  contains  at  most  ona  attributa-valua  pair  for 
aach  attributa  definad  in  tha  databasa.  Certain  attributa-valua  pairs  of  a 
racord  (or  a  f  i  la)  are  cal  lad  tha  directory  keywords  of  tha  record  (f  i  la) , 
because  either  tha  attributa-valua  pairs  or  their  attribute-value  ranges  are 
kept  in  a  directory  for  addressing  tha  record  (file).  Those  attributa-valua 
pairs  ¥vhich  are  not  kept  in  tha  directory  for  addressing  tha  racord  (file)  are 
cal  led  non-directory  keywords.  Tha  rest  of  tha  record  is  taxtCMl  information, 
which  is  referred  to  as  tha  racord  body.  An  example  of  a  racord  is  shown 
below. 


Tha  angle  brackets,  <,>,  enclose  an  attributa-valua  pair,  i.a.,  keyword.  Tha 
curly  brackets,  include  tha  record  boely.  Tha  first  attribute-value  pair 
of  all  records  of  a  file  is  tha  same.  In  particular,  tha  attributa  is  FBJE 
and  tha  valua  is  tha  file  name.  A  record  is  enclosed  in  tha  parenthesis.  For 
example,  tha  above  sanpla  racord  is  from  tha  Census  f  i  la. 

Tha  databasa  is  accessed  by  indexing  on  directory  keywords  using  keyword 
predicates.  A  keyword  predicate  is  a  tuple  consisting  of  an  attribute,  a 
relational  operator  (=,  !=,  >,  <,  >s,  <=),  and  an  attribute  value,  e.g. ,  POPU¬ 
LATION  >e  20000  is  a  keyword  predicate.  Mbre  specifically,  it  is  a  greater- 
than-or-equal-to  predicate.  Combining  keyword  predicates  in  disjunctive  nor¬ 
mal  form  characterizes  a  query  of  the  database.  The  query 

{ HU ;  ass  sa  a? : 

will  be  satisfied  by  al I  records  of  the  Census  f i le  with  the  CITY  of  either 
Monter^  or  San  Jose.  For  clarity,  w«  also  emplcy  parentheses  for  bracketing 
predicates  in  a  query. 

2.2.  The  Attribute  Baaed  Data  Language 

MBD6  is  designed  to  perform  the  prima.'Y  database  operations,  INSBTT, 
DRFTE,  UPDATE,  arwl  PE1RIEVE.  Additionally,  an  aggregate  operation  (i.e., 
AVG,  COUNT,  SUM,  MIN,  or  may  be  applied  when  using  the  NblKJLbVE  opera¬ 
tion.  Users  access  MBD6  through  the  host  computer  or  the  control  ler  by  issu¬ 
ing  a  request.  A  request  is  a  primary  operation  along  with  a  qualification.  A 
qualification  is  used  to  specify  the  information  of  the  database  that  is  to  be 


perfoniwd  by  the  primary  operation.  A  user  may  wish  to  treat  two  or  more 
requests  as  a  transaction.  In  this  situation,  li/BOS  executes  the  requests  of 
the  transaction  without  permuting  them,  i.e.,  if  T  is  a  transaction  containing 
the  requests  then  kfiOS  executes  the  request  Rl  before  the  request 

R2.  Finally,  we  olefine  the  term  traffic-unit  to  represent  either  a  single 
request  or  a  transaction  in  execution. 

Now,  let  us  examine  the  retrieve  request,  the  main  focus  of  our  study  in 
this  paper.  An  example  of  a  retrieve  request  would  be: 

RETRIEVE  (  (FILE  =  Census)  and  (PCPOATION  >  iOOOO)  )  (CITY) 

which  retrieves  the  names  of  al I  those  cities  in  the  Census  fi le  whose  popula¬ 
tion  is  greater  than  10000.  Notice  that  the  qua  I  if i cation  component  of  a 
retrieve  requ?*^  consists  of  two  parts:  the  query  which  specifies  records  of 
the  database  to  be  retrieved  and  the  target  I ist  which  specifies  the 
attribute-value(s)  to  be  returned  to  the  user.  Aggregate  operators  may  be 
applied  to  attributes  listed  in  the  target  list.  In  this  example,  there  is 
the  query  of  two  predicates  ((FILE  =  Census)  and  (POPLLATIGN  >  10000))  and  the 
target  I  ist  (CITY)  . 

2.3.  The  Directory  Tables 

To  manage  the  database  (often  referred  to  as  user  data),  uses  direc¬ 

tory  data.  Directory  data  in  corresponds  to  attributes,  descriptors,  and 
clusters.  An  attribute  is  used  to  represent  a  cat^ory  of  the  user  data;  e.g., 
POPtLATICM  is  an  attribute  that  corresponds  to  actual  populations  stored  in 
the  database.  A  descriptor  is  used  to  describe  a  range  of  values  that  an 
attribute  can  have;  e.g,  (10001  <  POPLLATIQN  <  15000)  is  a  possible  descriptor 
for  the  attribute  POPLLATIQN.  The  descriptors  that  are  defined  for  an  attri¬ 
bute,  e.g.,  population  ranges,  are  mutually  exclusive.  Now  the  notion  of  a 
cluster  can  be  defined.  A  cluster  is  a  group  of  records  such  that  every  record 
in  the  cluster  satisfies  the  same  set  of  descriptors.  For  example,  al  I  records 
with  POPULATION  between  10001  and  15000  may  form  one  cluster  whose  descriptor 
is  the  one  given  above.  In  this  case,  the  cluster  satisfies  the  set  of  a  sin¬ 
gle  descriptor.  In  reality,  a  cluster  tends  to  satisfy  a  set  of  multiple 
descriptors. 

Directory  information  is  stored  in  three  tables:  the  Attribute  Table 
(AT),  the  Descriptor-to-Oescriptor-Id  Table  (DDIT)  and  the  Cluster-Definition 


Table  (COT),  examples  of  which  are  given  in  Figure  2.  The  Attribute  Table  maps 
directory  attributes  to  the  descriptors  defined  on  them.  A  sample  AT  is  dep¬ 
icted  in  Figure  2a.  The  Descriptor-to-Oescriptor-Id  Table  maps  each  descrip¬ 
tor  to  a  unique  descriptor  id.  A  sample  ODIT  is  given  in  Figure  2b.  Note 
that  the  pointers  shown  in  Figure  2b  are  not  placed  in  the  DOIT  table  but  are 
shown  here  for  clarity  in  order  for  us  to  relate  to  the  AT  of  Figure  2a.  The 
C I uster-Def  i n i t i on  Table  maps  descriptor-id  sets  to  cluster  ids.  Each  entry 
consists  of  the  unique  cluster  id,  the  set  of  descriptor  ids  whose  descriptors 
define  the  cluster,  and  the  addresses  of  tfw  records  in  the  clusters.  A  sample 
COT  is  shown  in  Figure  2c  Thus,  to  access  the  user  data,  we  must  first  access 
directory  data  via  the  AT,  DOIT,  and  COT. 

In  designing  the  test  database,  one  of  the  key  concepts  is  the  choice  of 
the  directory  attributes  in  order  to  determine  the  necessary  descriptors  and 
therefore  clusters.  Thus,  we  provide  a  brief  introduction  to  the  three  clas¬ 
sifications  of  descriptors.  A  type-A  descriptor  is  a  conjunction  of  a  less- 
than-or-equa  I -to  predicate  and  a  greater-than-or-equa  I -to  predicate,  such  that 
the  same  attribute  appears  in  both  predicates.  For  example,  ((PDPU-ATION  >s 
10000)  and  (POPULATION  <=  15000))  is  a  type-A  descriptor.  A  type-B  descriptor 
consists  of  only  an  equality  predicate.  (FILE  s  Census)  is  an  example  of  a 
type-B  descriptor.  Final  ly,  a  type-C  descriptor  consists  of  the  name  of  an 
attribute.  The  type-C  attribute  defines  a  set  of  type-C  sub-descriptors. 
Type-C  sub-descr i ptors  are  equal ity  predicates  defined  over  al I  unique  attri¬ 
bute  values  which  exist  in  the  database.  For  example,  the  type-C  attribute 
CITY  forms  the  type-C  sub-descriptors  (CITYaCumberland)  and  (CITYaColumbus) , 
where  "Cumberland**  and  "Columbus"  are  the  only  unique  database  values  for  the 

fnv. 

2.4.  The  Execution  of  a  Retrieve  Request 

In  this  section,  we  describe  the  sequence  of  actions  for  a  retrieve 
request  as  it  moves  through  t^06.  The  sequence  of  actions  will  be  described  in 
terms  of  the  messages  passed  between  the  processes.  The  ^CD6  control  ler 
processes  are  Request  Preparation  (REQP) ,  Insert  Information  Generation  (IIG), 
and  Post  Processing  (PP) .  The  ^fi06  backend  processes  are  Directory  Management 
(Dt^,  Record  Processing  (RECP)  and  Concurrency  Control  (CQ .  For  completeness, 
we  describe  the  actions  which  require  data  aggregation. 


Attribute  Ptr 
POPU-ATICN  F 
OTY  Tc" 

FILE  F 

Figure  2a.  An  Attribute  Table  (AT) 

P->  0  <  POPULATION  <  50000  Dll 

50001  <  PCRJLATION  <  100000  D12 

100001  <  POPULATION  <  250000  D13 

250001  <  POPULATION  <  500000  014 

C->  CITY  =  Currberland  D21 

CITY  =  Columbus  D22 

F->  FILE  =  Employee  D81 

FILE  =  Census  D32 

Dij:  Descriptor  j  for  attribute  i. 

Figure  2b.  A  Descriptor-to-Oescriptor~Id  Table 
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{D11,D21,D31> 

A1,A2 

C2 

<D14,D22,D32} 

A3 

Figure  2c.  A  Cluster-Definition  Table  (CDT) 


Figure  2.  The  Directory  Tables 

First  the  retrieve  request  comes  to  HfeQp  from  the  host  computer  or  the 
control  ler  itself.  RBQP  sends  tiwo  messages  to  PP:  the  number  of  requests  in 
the  transaction  and  the  aggregate  operator  of  the  request.  The  third  message 
sent  by  RB3P  is  the  parsed  traffic  unit  which  goes  to  DM  in  the  backends.  DM 
sends  the  type-C  attributes  needed  by  the  request  to  CC.  Since  type-C  attri¬ 
butes  may  create  new  type-C  sub-descriptors,  the  type-C  attributes  must  be 
locked  by  CC.  Once  an  attribute  is  locked  and  descriptor  search  can  be  per¬ 
formed,  CC  signals  DM.  DM  will  then  perform  Descriptor  Search  on  m/n 
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pr«dicat«s,  n^r*  m  is  the  number  of  predicates  specified  in  the  query,  and  n 
is  the  number  of  backends.  DM  then  signals  CC  to  release  the  lock  on  that 
attribute.  DM  wi  1 1  broadcast  the  descriptor  ids  for  the  request  to  the  other 
backends.  DM  now  sends  the  descriptor- id  groups  for  the  retrieve  request  to 
OC.  A  descriptor-id  group  is  a  collection  of  descriptor  ids  which  define  a 
set  of  clusters  needed  by  the  request.  Descriptor-id  groups  are  locked  by  OC, 
since  e  descriptor-id  group  may  define  a  new  cluster.  Once  the  descriptor-id 
groups  are  locked  and  Cluster  Search  can  be  performed,  CC  signels  DM.  DM  wi  1 1 
then  perform  Cluster  Search  and  signal  CC  to  release  the  locks  an  the 
descriptor-id  groups.  Next,  DM  wi  1 1  send  the  cluster  ids  for  the  retrieval  to 
CC.  CC  locks  cluster-ids,  since  a  new  address  may  be  specified  for  an  exist¬ 
ing  cluster.  Ohce  the  cluster  ids  are  locked,  and  the  request  can  proceed 
with  Address  Generation  and  the  rest  of  the  request  execution,  CC  signals  DM. 
DM  will  then  perform  Address  Generation  and  send  the  retrieve  request  and  the 
addresses  toe  RECP.  Ohce  the  retrieval  has  executed  properly,  RECP  will  tell 
CC  that  the  request  is  done  and  the  lodes  on  the  cluster  ids  can  be  released. 
The  retrieval  results  are  aggregated  by  each  backend  and  forwarded  to  PP.  PP 
completes  the  aggregation  after  it  has  received  the  partial  results  from  every 
backend.  VPien  PP  is  done,  the  final  results  will  be  sent  to  the  user. 

3.  THE  BB«HyMV<  STRATEGY 

In  this  section  we  analyze  the  basic  benchmark  strategy  for  the  prelim¬ 
inary  performance  evaluation  of  the  multi-backend  database  system.  The  bench¬ 
mark  strategy  focuses  on  collecting  macroscopic  and  microscopic  measurements 
on  the  systems  performance.  Macroscopic  measurements  correspond  to  the  exter¬ 
nal  performance  measurement  of  the  system,  which  col  lects  the  response  time  of 
requests  that  are  processed  by  the  system.  Internal  performance  measurement 
involves  the  detai  led  measurement  of  the  working  processes  of  the  system.  In 
particular,  we  are  measuring  the  time  td<en  to  process  a  particular  message  in 
kED6.  Each  kBD6  process  has  a  group  of  functions,  cal  led  messagpe  handlers, 
that  control  and  oversee  the  processing  of  a  message.  The  time  spent  in  a 
particular  message  handler  is  collected  in  internal  performance  measurement. 

To  adequately  conduct  both  the  internal  and  external  performance  messurs 
swnt  of  the  system,  software  was  developed  to  ool  lect  timing  informstion  and 
data.  The  performance  software  was  bracketed  in  conditional  compilation 
atatssients  to  faci  litate  an  easy  transition  between  a  tasting  ayatsm  and  a 
rumipg  system.  Nb  constructed  two  aoftrare  bases  of  the  IlfiDS.  The  first 


oonsistad  of  th«  IkGDS  code  and  only  the  tasting  softiwara  raquirad  for  exte 
parfomianca  measurement.  The  second  had  the  tasting  software  for  both 
internal  and  external  performance  measurement  software  compiled  in.  We 
to  use  the  difference  in  timings  collected  from  the  two  bases  to  calculate 
overhead  incurred  by  the  addition  of  internal  performance  measurement 
software. 

The  rest  of  this  section  is  organized  as  follows.  First,  we  give  a 
high-level  description  of  the  test  database  organization  and  system  configura¬ 
tions  used  in  the  performance  evaluation.  Next,  we  present  a  detai  led  discus¬ 
sion  of  the  test  database  organization.  Third,  we  examine  the  request  set 
used  to  col  lect  the  timings.  Final  ly,  we  review  the  relevant  tests  that  are 
to  be  conducted,  and  the  measurement  statistics  that  are  col  lected  and  calcu¬ 
lated. 


3.1.  The  Test  Database  Organization  and  Testing  Configurations 

To  properly  evaluate  a  database  system,  various  record  sizes  need  to  be 
used.  The  sizes  are  chosen  based  on  the  size  of  the  unit  of  disk  management. 
In  kfiD6,  this  is  the  block.  MBD6  processes  information  from  the  secondary 
memory  using  a  4Kbyte  block.  Given  a  blocksize  of  4i<bytes,  it  was  recommended 
to  construct  the  database  with  record  sizes  of  200  bytes,  400  bytes,  1000 
bytes,  and  2000  bytes  [Stra84]  .  This  gives  a  range  of  2  to  20  records  per 
block.  Since  we  are  engaged  in  only  the  first  test  of  kCD6,  we  limited  the 
scope  of  the  testing  to  a  database  with  a  200  byte  record  size. 

In  addition,  the  virtual  and  physical  memory  limitations  of  each  backend 
restricted  the  database  size  to  s  maximum  of  1000  records  per  backend.  This 
limitation,  coupled  with  the  two  software  versions  of  the  system  and  the  need 
to  verify  the  two  performance  claims,  led  us  to  the  specification  of  five  dif¬ 
ferent  system  configurations  for  the  HiEDS  performance  measurements.  Table  1 
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Table  1.  The  Measurement  Configurations 


display  the  configurations. 

Testa  A.E,  B.E,  and  C.E  are  conducted  without  internal  performance 
software  in  place.  Test  A.E  configures  lyE06  with  one  backend  and  one  thousand 
records  in  the  test  database.  Test  B.E  configures  l/BDS  with  two  backends  and 
one  thousand  records  split  evenly  between  the  backends.  The  transition  from 
Test  A.E  to  Test  B.E  is  used  to  verify  the  first  performance  claim  (see  Sec¬ 
tion  1).  Test  C.E  also  configures  ll/BDG  with  two  backends,  but,  the  size  of 
the  database  is  doubled  to  two  thousand  records.  The  transition  from  Test  A.E 
to  Test  C.E  is  used  to  verify  the  second  performance  claim  (see  Section  1) . 
Test  A. I  and  B.I  are  conducted  with  internal  performance  aoftware  in  place. 
Test  A. I  configures  with  one  backend  and  one  thousand  records  in  the  test 
database.  Test  B.I  configures  kfiOS  with  two  backends  and  one  thousand  raoords 
spl  it  evenly  between  the  backends.  The  transitions  from  A.E  to  A. I  and  from 
B.E  to  B.I  are  used  to  determine  the  overhead  ir^rred  by  the  addition  of 
internal  performance  measurement  software.  Overall,  using  these  five  oonfi- 
gurmtions,  the  verification  of  the  ikiEDS  performance  and  capacity  claims  is 
simplified  and  the  performarK:e  measurement  methodology  of  computing  the  inter¬ 
nal  measurement  overhead  is  faci  I  itated. 

3.2.  The  Ostai  led  Test  Oatabese  Organization 

We  have  chosen  the  test  record  size  to  be  200  bytes.  The  20O-byte  record 
minimizes  the  primary  memory  required  to  store  the  record  template.  In  actu¬ 
ality,  a  record  of  196  bytes  is  used.  The  rmoord  consists  of  33  attributes, 
each  requiring  6  bytes  of  storage.  The  record  template  is  used  to  specify  the 
attributes,  both  the  directory  and  the  non-directory  attributes,  of  the 
record.  Of  the  33  attributes  listed  (see  Figure  3),  INTEl  and  INTE2  are 
directory  attributes.  MULTI  and  SIROO  to  STR29  are  non-directory  attributes. 


Figure  3.  The  Record  Template 


The  descriptor  types  and  the  descriptor  ranges  for  the  two  directory 
attributes,  INTEl  aixi  INTE2,  must  also  be  defined.  The  values  for  INIEl  are 
classified  by  using  five  type-A  descriptors,  each  of  which  represents  a  range 
of  200,  i.e.,  the  ranges  would  be  [1,200],  [201,400],  ...,  [801,1000],  where 
[a,b]  is  used  to  represervt  the  type-iA  descriptor  range.  The  values  for  1NTE2 
are  also  classified  using  type-A  descriptors.  The  first  twenty- three  ranges 
for  INTE2  cover  40  values,  with  the  last  range  coverir>g  80  values,  i.e.,  the 
type-nA  descriptor  ranges  would  be  [1,40],  [41,80],  ...,  [881,020],  [021,1000]. 
The  INTE2  descriptor  ranges  are  not  uniform. 

Next,  we  examine  the  records  which  are  generated  and  stored  in  the  test 
database.  INTEl  and  INTE2  have  identical  value,  i.e.,  numbers,  being  the  next 
sequential  number  after  the  previous  record,  starting  at  1.  Therefore,  the 
one  thousandth  record  would  have  the  (INTEl,  INT^)  pair  set  to  1000.  The 
MXn  attribute,  which  is  of  the  type  of  character  string,  is  set  to  One  for  a 
database  of  only  1000  records.  The  intent  of  this  attribute  is  to  increase 
the  number  of  records  per  cluster  in  the  database.  This  is  done  by  setting 
MULTT  to  Two,  Three,  etc.,  for  each  (INTEl,  INT^)  pair  in  the  database. 
Therefore,  to  double  the  size  of  the  database,  every  (INTEl,  INT^)  pair  will 
have  an  associated  MiLTI  attribute  with  values  of  One  and  Two.  The  remaining 
attributes,  STNOO  to  Sn^29,  are  set  to  }0(xxx  as  f  i  I  lers  for  the  rest  of  the 
record  body.  Figure  4  depicts  the  general  layout  of  the  f  i  le  for  1000  records 
where  MULTI  is  set  to  One. 


INTEl  I  INTE2  |  MU.TI  |  STROO  |  STT«>1  | 


One  I  ^xxx 
One  I  Xxxxx 


Xxxxx 

Xxxxx 


1000  I  1000  One  I  Xxxxx  I  Xxxxx 


Xxxxx 

Xxxxx 


Xxxxx 


Figure  4.  The  Generated  Records 

The  cross-product  of  INTEl  ranges  and  INTE2  ranges  has  resulted  in  the 
specification  of  24  descriptor  groups  for  the  INTEl  and  INT^  attributes.  Cou¬ 
pled  with  the  record  template,  they  generate  a  test  database  that  contains  24 
clusters.  The  first  23  clusters  contain  40  records  each.  The  last  cluster 
contains  80  records.  To  maintain  consistency  in  the  retrieval  requests  (dis- 
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in  th«  n«xt  aaction),  wa  avoid  any  raquaata  that 
in  tha  taat  databaaa  uaing  tha  INTE2  attribuia. 


tha  laat  60 


3.3.  Tha  Raquaat  Sat 
Tha  raquaat  aat  i 


Tha  raquaat  aat  uaad  for  our  parformanca  aaaaurnant  ia  givan  in  Figura 
6.  Tha  ratriavala  ara  a  mix  of  aingla  or  double  pradicata  raquaata.  Sinea 
tha  majority  of  tha  work  dona  on  a  databaaa  is  to  ratriava  data,  wa  I  imit  our 
first  maasuramants  to  only  ratriava  raquaata.  In  ovary  raquaat,  1/2  of  tha 
target  attribute  values  for  each  record  is  ratumad.  Tha  first  raquaat  ia  for 
only  two  records  from  two  separate  clusters.  Tha  second  request  ratriavas  1/4 
of  the  database.  Seven  of  tha  24  clusters  must  be  examined.  All  records  in 
each  of  tha  first  six  clusters  ara  retriavad.  Only  1/4  of  tha  seventh  clus¬ 
ter,  defined  by  tha  1NTE2  range  from  241  to  2B0,  ia  retriavad.  In  tha  third 
request,  1/2  of  tha  databaaa  is  retriavad.  Thirtaon  of  tha  24  ciustara  must 
be  examined.  All  records  in  each  of  the  first  twelve  ciustara  ara  ratumad. 
Only  1/2  of  tha  thirteenth  cluster,  defined  by  tha  1NTE2  range  from  481  to 
520,  is  retrieved.  Tha  system  searches  only  for  records  having  values  in  tha 
INTE2  range  from  461  to  SOO  in  this  cluster. 


Tha  entire  databaaa  is  examined  in  the  fourth  raquaat.  Tha  fifth  request 
retrieves  2/5  of  tha  databaaa.  lha  query  ia  divided  into  two  pradicataa,  to 


Request  Number  | 


Retrieval  Request 
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obtain  all  raoorda  from  tha  first  fiva  cluatars,  and  tha  last  four  clustars. 
Tha  sixth  raquaat  is  a  ratriaval  of  4/S  of  tha  dstabasa.  Agsin  tha  quat^  is 
dividad  into  tao  pradicatas,  to  obtain  al  I  raoords  from  tha  first  10  clustars, 
and  tha  last  nina  clustars. 

Tha  savanth  and  ai^bth  raquasta  ara  similar  in  intant.  Tha  aavanth 
raquaat  axaminas  10  clustars,  raquiring  only  1  raoord  to  ba  ratriavad  from  tha 
6th  clustar  and  naading  all  raoords  from  tha  first  fiva  clustars.  Tha  aiflhth 
raquaat  axaminas  15  clustars,  raquiring  only  1  raoord  to  ba  ratriavad  from  tha 
11th  clustar  stkI  naading  all  raoords  from  tha  first  tan  clustars.  Tha  ninth 
arxi  final  raquaat  is  similar  to  tha  fifth  raquaat.  But  uni ika  tha  fifth 
raquast,  tan  additional  clustars  must  ba  axaminad.  Only  two  of  tha  raoords 
with  INIEl  valuaa  of  201  and  801,  ara  ratriavad  from  tha  tan  additional  clus¬ 
tars.  All  raoords  in  tha  ramaining  nirw  clustars,  I ika  tha  fifth  raquast,  ara 
also  obtainad  by  this  ratriaval.  Tdbla  2,  a  prasantation  of  tha  nuabar  of 
clustars  axamir^  varsua  tha  parcant  of  tha  dstabasa  ratriavad,  is  a  syrwpsis 
of  tha  pravious  discussion  in  tabular  form. 

3.4.  Tha  Measuramant  Stratagy,  Statistics  and.  Limitatiorw 

Tha  basic  maasuramant  statistics  usad  in  tha  parformanca  avaluation  of 
k036  is  tha  rasponsa  tima  of  raquast(s)  that  ara  procassad  by  tha  dstabasa 
systam.  Tha  rasponsa  time  of  a  raquast  is  tha  time  batwaan  tha  initial 


nunbar 


Number  of 

CTusVars 

Examined 


Voluma  of 
Rat^ia^ 


2  raoorda 


2SX 


5GK 


lOOK 


40K 


808 


208  1  record 


408  *  1  record 


408  +  2  raoords 


Table  2.  Tha  Number  of  Ciustars 
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issuance  of  tha  raqwaat  hjf  tha  uaar  and  tha  final  racaipt  of  tha  antina 
raquaat  aat  for  tha  requaat.  lha  raaponaa  tinwa  ara  eol  lactad  for  tha  raquaat 
aat  (aaa  Figura  S)  for  aaeh  of  tha  fiva  oonf  igurationa  (aaa  Tahia  1).  Bach 
raquaat  is  aant  a  total  of  tan  timas  par  databaaa  oonf  iguration.  lha  raaponaa 
tima  of  aach  raquaat  is  racordad.  Wd  datarmina  that  tan  rapatitions  of  aaeh 
raquaat  produca  an  accaptabla  standard  daviation.  Mpon  oomplation  of  tha  tan 
rapatitions  for  a  raquast,  wa  calculata  tha  maan  and  tha  ^andard  daviation  df 
tha  tan  raaponaa  timas.  Thara  ara  tao  main  statistics  that  me  calculata  to 
avaluata  tha  parformanca  claims,  tha  rasponsa-tima  improvamant  and  tha 
raaponaa-tima  raduction. 

f^aponaa  tima  improvamant  is  dafinad  to  ba  tha  paroantaga  improvaawnit 
in  tha  raaponaa  tima  of  a  raquast,  ahan  tha  raquaat  is  axacutad  in  n  hackanda 
as  oppoaad  to  ona  backand  and  tha  nunbar  of  racords  in  tha  iatahaaa  ramains 
tha  Sana.  Equation  1  providaa  tha  formula  uaad  to  calculata  tha  raaponaa  tima 
improvamant  for  a  particular  raquaat,  ahara  Configuration  B  rapraaanta  n  hack 
ands  and  Configuration  A  raprasants  ona  backand.  lha  raaponaa  tima  inpmuaiaant 
is  calculatad  for  tha  configuration  pairs  (A.E,  B.^)  and  (A.I,  B.I),  rupir 
tivaly.  lha  configuration  pair  (A.E,  B.Q  is  avaluatad  for  tha  ratriava 
racpjaats  (1)  through  (9)  (aaa  Tablas  5  and  B).  lha  pair  (A.I,  B.I)  is 
avaluatad  only  for  tha  ratriava  raquaata  (1)  through  (6).  Ovarali,  tha 
diffaranca  in  tha  oo  I  lactad  timas  of  tha  two  oonf  igurationa,  i.a.,  (A.I - 
A.^,  and  (B.I  >  B.E),  raspacti valy,  should  provida  us  with  a  maaaura  of  tha 
ovarhaad  incurrad  whan  intamsi  parformanca  maaauramant  aoftwara  is  praoant  in 
tha  systam. 

lha.  Raaponaa 
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»  ^  -r.  Configuration  A 

Raaponaa  T iiw  *  lOOB - =: — -  *  lOOK 

Improvamant  lha  Raaponaa 


Conf  i^rstion  B 

Equation  1.  lha  Raaponsa-Tima-Improvamant  Calculation 

lha  raaponaa  tima  raduction  is  dafinad  to  ba  tha  raduction  in  raaponaa 
tima  of  a  raquast,  whan  tha  raquaat  is  axacutad  in  n  bsckands  containing  nx 
numbar  of  racords  as  oppoaad  to  ona  backand  with  x  numbar  of  racords.  Equa¬ 
tion  2  providaa  tha  formula  uaad  to  calculata  tha  tha  raaponaa-tima  raduction 
for  a  particular  ratriavsl  raquaat,  whara  configuration  A  rapraaanta  ona  back- 
and  with  x  raoorda  and  configuration  B  rapraaanta  n  bsckands,  aach  with  x 


rttoorob.  in«  responM-tinw  raduction  is  csiculatsd  for  the  configuration  pair 
(A.E,  for  the  retrieve  requests  (1)  through  (0). 
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Equation  2.  The  Response  Time-Reduction  Calculation 


The  internal  processing  times  of  the  message-handling  routines  nihich  are 
used  to  process  a  retrieval  request  are  also  timed.  Retrieval  (1)  and 
Retrieval  (2)  are  selected  to  conduct  internal  timing.  These  requests  are 
selected  since  they  retrieve  the  smallest  portion  of  the  test  database  and  the 
processing  time  for  each  request  is  minimal.  Each  message-handling  routine  is 
timed  independently  of  all  others  and  each  routine  must  process  multiple 
requests  so  that  an  accurate  average  may  be  computed  for  the  time  required  to 
process  that  request  type.  Sixteen  message-handling  routines  are  required  to 
process  a  retrieve  request.  If  we  send  twenty  requests  to  each  routine,  a 
total  of  320  requests  must  be  processed  by  MBD6.  Based  on  these  figures,  the 
time  required  to  conduct  the  internal  performance  measurement  of  a  retrieval 
that  has  a  response  time  of  twenty  seconds  wi  1 1  be  approximately  107  minutes. 
This  figure  does  not  include  the  administrative  time  required  to  process  the 
internal  measurement  data.  For  this  reason,  we  limited  the  internal  perfor¬ 
mance  measurement  requests  to  requests  (1)  and  (2) . 


Additionally,  we  also  limited  the  number  of  repetitions  per  message 
handler  to  twenty.  This  is  done  to  reduce  the  processing  time  per  message 
handler.  However,  this  decision  reduces  the  accuracy  of  the  internal  perfor¬ 
mance  measurement,  from  ten-thousands  to  hundredths  of  a  second.  Thus,  the 
internal  performance  measurement  times  provide  only  a  rough  estimate  of  the 
time  required  to  handle  the  respective  messages.  There  are  additional  limita¬ 
tions.  The  last  two  versions  of  differ  in  the  implementation  of  the 
directory  tables,  i.e.,  the  AT,  the  OOIT,  and  the  CDT.  The  newest  version  of 
the  system,  cal  led  Version  F,  implements  the  directory  tables  on  the  secondary 
storage.  The  previous  version,  called  Version  E,  stored  the  directory  tables 
in  the  primsry  memory.  The  major  roadblock  that  we  have  encountered  in  the 
performance  measurement  of  has  been  the  hardware  I  imitations  of  the  back- 


•nd  proc wor«  ^CP-l  1/44)  .  With  only  64K  of  virtual  — wory  par  proooaa  and  a 
total  of  2S6K  physical  iwaory,  wa  found  that  wa  could  not  ineraaaa  tha  1606 
ayatam  paraaatara  to  parmit  an  axtanaiva  tast  of  tha  ^^stam  on  a  larga  data- 
baaa.  Thaaa  rastrictiona  hava  forcad  ua  to  banchwark  tha  priaary  waaorybaaad 
diractory  aanagamant  varsion  of  tha  systaai  ahrch,  axeludii^  tha  diractory 
tabla  aanajuant  routinaa,  is  navarthalasa  aqMivalant  in  functionality  to  Var- 
aion  F. 

4.  IfE  BBCHMNKINQ  ReSU.lS 


In  this  aaction,  we  present  the  results  obtained  froai  tha  parforaanca 
aaasuraaant  of  1606.  We  also  review  tha  results  of  external  parforaanca  aaas- 
uraaant,  overhead  incurred  by  internal  parforaanca  aaaauraaant.  aoftaara  and 
internal  parforaanca  aaaauraaant.  One  final  noba»  tha  units  of  aaasuraaant 
prasantad  in  tha  tables  of  this  section  are  expressed  in  seconds. 

4.1.  Tha  Extamal  Parforaanca  tiaaauraaant  Results 

Tabla  3  provides  tha  results  of  tha  external  parforaanca  aaasuraaant  of 
1606  without  tha  internal  parforaanca  aasaureaent  software.  There  are  three 
parts  to  Tabla  3.  &ch  part  contains  the  aean  and  tha  standard  deviation  of 
tha  rsaponaa  tiaas  for  requests  (1)  throMS^  (9),  which  are  outlined  in  Section 
3.3.  Tha  three  parts  of  Tabla  3  represent  three  different  configurations  of 
tha  1606  hardware  and  tha  database  capacity.  Tha  first  part  has  configured 
1606  with  one  backend  and  tha  database  with  1000  records  on  its  disk.  Tha 
second  part  has  configured  1606  with  two  backends,  with  tha  database  of:  1000 
record,  split  evenly  between  the  disks  of  the  backerxis.  The  third  part  has 
configured  1606  with  two  backerxls  and  with  a  database  doubled  of  2000  reoords, 
where  the  disk  of  each  backend  has  100  reoords.  In  Table  3  we  notice  one  data 
arKnaly,  the  standard  deviation  for  request  (0)  in  the  one  backerKi  eith-1000- 
reoords  configuration.  Since  we  did  not  oorxJuct  an  internal  parfonsanee  swaa- 
urenient  on  this  request,  we  are  not  sure  «dist  causes  this  skewed  standard 
deviation,  and  hence  will  not  sttespt  to  offer  an  explarwtion  of  this  arwnely. 


Given  the  data  presented  in  Table  3,  we  can  now  attempt  to  verify  or 
disprove  the  two  1606  performance  claims.  Ws  begin  by  calculatirig  the 
reaporms  time  improvement  for  the  nine  requests.  In  Table  4  we  present  tha 
response-time  isprovement  for  the  data  givmi  in  Table  3.  Notice  that  the 
reaponss  time  isprovemant  is  lowest  for  request  (1),  which  represents  a 
retriaval  of  two  records  of  the  database.  On  the  other  hard,  the  reaporrea  time 
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improvement  of  request  (4),  wihich  retrieves  all  of  the  database  information  is 
his^iest,  approaching  the  upper  bound  of  fifty  percent.  In  general,  wo  find 
that  the  response-time  improvement  increases  as  the  number  of  records 
retrieved  increases.  This  seems  to  support  a  hypothesis  that  even  if  the  data¬ 
base  is  larger,  the  response-time  improvement  will  remain  at  a  relatively  hi{^ 
(between  40  an  50  percent)  I  eve  I . 

Next,  wo  calculate  the  response-time  reduction  for  each  of  the  nine 
request.  In  Table  5  we  present  the  response-time  reductions  for  the  data  given 
in  Table  3.  Notice  that  the  response-time  reduction  is  worst  for  request  (1), 
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which  represents  a  retrieval  of  two  records  of  the  database.  On  the  other 
hand,  the  responae-tieie  reductions  for  the  requests  which  access  larger  por¬ 
tions  of  the  database,  requests  (4)  and  (6),  have  only  a  small  response-time 
reduction.  In  general,  we  found  that  the  response  time  reduction  decreases  as 
the  number  of  records  retrieved  increases,  i.e.,  the  response  time  remains 
virtually  constant.  Again  we  seem  to  have  evidence  to  support  the 
hypothesis  that,  as  the  size  of  the  response  set  increases  for  the  same 
request,  the  response-time  reduction  will  decrease  to  a  relatively  low  (  O.lX 
or  less  )  level . 


Table  6  provides  the  results  of  external  performance  measurement  of  llEDS 
with  internal  performance  measurement  software  in  place.  There  are  two  ports 
to  Table  6.  Each  part  contains  the  mean  and  the  standard  deviation  of  the 
response  times  for  the  requests  (1)  through  (6).  The  two  parts  of  Table  6 
represent  two  different  configurations  of  the  llEDS  hardware  and  the  database 
capacity.  Part  one  has  configured  MEDS  with  one  backend  and  with  the  database 
of  1000  records.  Part  two  has  configured  ftSS  with  two  backends,  with  the 
dat abase  of  1000  rsoords,  split  evenly  between  the  disks  of  the  backends.  We 
did  not  measure  the  rssponss  times  with  two  thousand  rsoords  distributed  over 
two  backends.  Ws  felt  that  no  additional  information  would  be  gained  by  con¬ 
ducting  the  maaaursmsnts. 
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4.2.  The  Internal  Performance  Measurement  Overhead 

An  interesting  anomaly  is  discovered  when  we  compare  the  responste  times 
of  the  external  and  internal  performance  measurement  tests,  i.e.,  ports  one 
and  two  of  Tables  3  and  6  for  requests  (1)  through  (6).  We  had  anticipated 
that  the  addition  of  internal  performance  measurement  software  would  add  an 
overhead  to  the  response  time  of  requests.  In  the  transition  from  A.E  to  A. I 
and  from  B.E  to  B.I  we  expected  there  to  be  in  an  increase  in  the  response 
times  for  the  common  requests.  We  actually  found  a  general  improvement,  from 
O.lJt  to  SX,  in  the  response  times  of  the  requests  when  the  internal  perfor¬ 
mance  measurement  software  is  part  of  the  code.  What  could  have  caused 
the  anomaly?  One  hypothesis  is  that  this  is  due  to  the  msnner  in  which  k/BD6 
is  implemented  on  the  backends.  Currently,  there  is  not  sufficient  virtusi 
memory  per  process  aval  lable  on  each  backend.  The  result  is  that  disk  overlays 
are  used  to  organize  the  code  for  each  process  in  kfiOG.  The  additional  inter¬ 
nal  performance  measurement  code  may  cause  the  operating  system  to  overlay 
differently,  thereby  benefiting  the  overa  1 1  performance  of  kED6.  We  still 
believe  that  there  is  an  overhead  induced  by  the  internal  measurement  oode  and 
Table  7  provides  evidence  by  demonstrating  that  the  response-time  improvement 
achieved  by  adding  a  backend  is  inferior  to  the  corresponding  figures  in  Table 
4. 
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4.3.  The  Internal  Performance  Measurement  Results 

Table  8  provides  the  results  of  the  internal  performance  maasuramant  of 
kBOS  for  a  retrieval  request.  The  times  measured  for  each  message-handling 
routine  are  given  for  both  request  (1)  and  (2).  The  maseaga  handling  routines 
are  listed  with  the  liBDS  process  whid>  contains  the  routine.  Althoqgb  the 
results  are  given  to  four  decimal  places,  we  only  trust  the  accuracy  to  tha 
second  decimal  place  (see  Section  3.4).  Basically,  what  can  we  observe  about 
the  col  lected  message -handl  ing  times?  We  see  that  the  control  ler  prooesaes, 
i.e.,  Request  Preparation  and  Post  Processing,  spend  very  little  time  in  pro¬ 
cessing  the  retrieval  request.  This  is  a  major  design  goal  of  ICDS  and  is 
necessary  to  prevent  a  bottleneck  at  the  control  ler  when  the  number  of  back¬ 
ends  increases  substantial  ly.  It  appears  that  this  goal  is  met  successful  ly. 
We  also  observe  that  the  results  obtained  from  Concurrency  Control  are  con¬ 
sistent  and  of  short  duration.  This  is  expected  since  there  is  only  one 
request  in  the  system  at  a  time  and  no  access  contention  can  occur.  These 
tables  should  then  be  considered  as  containing  the  best  case  times.  The  major¬ 
ity  of  work  done  in  the  backend  is  at  Record  Processing.  Observing  the  process 
timings  in  Record  Processingi  we  see  that,  for  both  requests,  the  addition  of 
an  extra  backend  reduces  the  record  processing  time  by  nearly  half. 

6.  CONOISIONS  AM)  RmBE  WORK 

We  have  shown  that  the  two  basic  performance  claims  of  the  multi-backend 
database  system  are  valid.  While  these  results  are  prelimirwry,  thay  are 
encouraging.  Overall,  the  response  time  improvement  ranged  from  36.07  percent 
to  48.04  percent,  when  the  number  of  bsckerxis  and  their  disks  is  doubled  for 
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that  ««e  made  «ws  that  the  results  were  consistent  and  reproducible.  Ihe  tests 
were  conducted  at  least  twice  for  most  of  the  request  set,  with  the  testing 
done  on  different  days  by  different  people.  The  resulting  date  was  consistent 
and  reproducible.  The  data  presented  in  this  paper  represents  the  last  set  of 
tests  for  the  request  set. 

The  next  logical  step  in  the  performance  of  the  multi -backend  database 
system  is  to  extend  the  testing  to  include  the  other  request  types,  update, 
insert  and  delete.  Additional  ly,  there  are  sti  1 1  some  more  tests  to  run  on 
the  retrieval  request.  We  should  also  investigate  the  effect  of  the  direc¬ 
tory  structure  on  performance.  In  particular,  we  should  try  to  determine  how 
much  of  an  effect  the  descriptor  definitions  for  a  directory  attribute  have  on 
the  performance  data.  Finally,  we  should  conduct  some  tests  on  the 
secondary  memory  version  of  the  directory  tables  to  evaluate  just  how  much  an 
effect  this  version  wi  1 1  have  on  the  perfonmmee  data. 

Because  MBDS  is  intended  for  microprocessor-based  backends,  winchester- 
type  disks  arxl  an  Ethemet-I  ike  broadcast  bus,  we  wi  1 1  not  continue  our  bench¬ 
mark  work  on  the  present  >MX-PfPs  configuration.  Instead,  we  plan  to  download 
10)6  to  either  MicnoVaxs  or  Sun  Workstations.  With  either  choice,  we  can 
utilize  a  brxiedcast  bus,  mbich  was  nob  avai Isble  when  the  project  began.  We 
may  also  elimirwte  all  the  physical  and  virtual  memory  problems.  In  the  new 
environment  we  can  perhaps  obtain  a  more  accurate  measurement  of  the  internal 
performance  meaeurament  software  overhead,  conduct  a  more  thorough  benchmark¬ 
ing  of  10)6,  and  study  various  benchmarking  strategies. 
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